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METHOD AND APPARATUS FOR XML DATA STORAGE, 
QUERY REWRITES, VISUALIZATION, MAPPING AND REFERENCING 

RELATED APPLICATIONS; PRIORITY CLAIM 

This application claims priority firom U.S. Provisional Patent Application Serial 
Number 60/230,878 filed on September 7, 2000 entitled "XML DATA STORAGE, 
QUERY REWRITES, VISUALIZATION, MAPPING AND REFERENCING", by 
inventors Muralidhar Krishnaprasad, Viswanathan Krishnamurthy, and Ravi Murthy. 

This application claims priority from U.S. patent application serial number 

, Attorney Docket No. 50277-1 564, entitled "METHOD AND APPARATUS 

FOR XML VISUALIZATION OF A RELATIONAL DATABASE AND UNIVERSAL 
RESOURCE IDENTIFIERS TO DATABASE DATA AND METADATA," naming as 
inventors Muralidhar Krishnaprasad, Viswanathan Krishnamurthy, Ravi Murthy. 

This application claims priority from U.S. patent application serial number 

, Attorney Docket No. 50277-1565, entitled "APPARATUS AND METHOD 

FOR MAPPING RELATIONAL DATA AND METADATA TO XML," naming as 
inventors Muralidhar Krishnaprasad, Viswanathan Krishnamurthy, Ravi Murthy and 
VisarNimani. 

This application claims priority from U.S. patent apphcation serial number 

, Attorney Docket No. 50277-1566, entitled "METHOD AND APPARATUS 

FOR FLEXIBLE STORAGE AND UNIFORM MAMPULATION OF XML DATA IN 
A RELATIONAL DATABASE SYSTEM", naming as inventors Muralidhar 
Krishnaprasad, Viswanathan Kjidmamurfhy, and Ravi Murthy. 

FIELD OF THE INVENTION 

The present invention relates generally to relational databases and, more 
specifically, to XML visualization of a database, DBURI references to database objects, 
mapping relational database data and metadata to XML data, providing XML data in 
response to XML queries, and XML data storage, manipulation and queriability. 

BACKGROUND OF THE INVENTION 

On the World Wide Web, there is a need to reference data from different sources 
inside documents. The standard way of referencing such data is through the use of URIs - 
or universal resource identifiers. Since a vast majority of the data lies inside relational 
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databases, it is necessary to support a standard URI based access methods to such data. 
Typically, such applications are written using standard mechanisms like Servlets, which 
in-tum may execute SQL statements to retrieve and format the database data. Significant 
processing is often needed to convert the results of the SQL data into a standard format 
required by the user, such as extensible Markup Language (XML). XML is a World 
Wide Web Consortium (W3C) standard for representing data. 

Data within relational databases are typically accessed by sending commands to 
database servers that manage the databases. Such commands must conform to a database 
language supported by the database server. 

Many applications are now being designed to expect input data in the form of 
XML documents. When the data provided to the applications comes firom a relational 
database, the data typically has to be reformatted into an XML documait. 

When data is presented as an XML document, the recipient of the document must 
understand the structure of the XML document When the XML document is generated 
ficom the result of a relational database query, the structure of resulting XML document 
will typically vary based on the nature of the query. Consequently, the process of 
transforming the relational data to an XML document, and generating data that mdicates 
the stracture of the XML document thus produced, can be cumbersome and inflexible. 

Various techniques maybe used to store data from such XML documents into a 
relational database. According to one technique, each XML docmnent is treated as a 
single data item, and stored as such in a single column of a relational table. This 
technique is convenient m that the XML does not have to be processed before it is 
submitted to the database server. However, because the database server considers tiie 
XML document a single data item, the database server is unable to take advantage of the 
fact that XML documents are structured, where a single XML document may include 
numerous attributes and elements with specific values. 

According to an alternative technique, an XML document may be split up into its 
constituent attributes and element data before the XML document is stored in a database. 
The values for each attribute and element are submitted to the database for insertion in 
corresponding colimms of a table. When this technique is used, the database server may 
be used to select data based on individual attribute values. However, when the data is 
retrieved from the database, the attribute values are provided as distinct data items, not as 
part of a single XML document. To recover the XML document, tlie data received from 
the database server must be reformatted and structured to reconstruct the XML document. 
-2- 
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Based on the foregoing, it is clearly desirable to provide a less cumbersome 
mechanism and technique for allowing clients, such as browsers, that support accessing 
resources using URLs, to access relational data. 

Further, it is desirable to provide techniques for transforming relational data into 
XML in an intelligent, flexible and efficient manner. 

It is desirable to provide techniques for handling XML documents that do not 
depend on the specific form in which they are stored. In other words, it is desirable for 
applications to independently decide on the storage representation of their XML data, and 
that does not have any impact on the functionality. However, the choice of storage could 
potentially affect performance of the apphcations. Further it is also desirable for the 
database server to implement techniques that exploit the chosen storage representation for 
optimal processing of user operations. 

SUMMARY OF THE INVENTION 

Techniques are provided for allowing a user to view and retrieve data fi:om a 
relational database in XML format. Techniques are provided for (1) tiie user to access 
this data through the World Wide Web by providing URI references to such data, and (2) 
to store and perform operations on these URI references inside the database. 

Techniques are also provided for using XML syntax in exchanging data with 
relational databases. Users may navigate through those "visualized" portions of the 
database using XPath expressions. 

Techniques are provided for mapping metadata and data in relational databases to 
XML data. According to certain embodiments of the invention, a mechanism is provided 
to allow the user to xise a database query to retrieve data firom a relational database in fhe 
form of XML documents by candnically mapping object relational data to XML data and 
canonically mapping object relational schemas to XML-Schemas, XML Namespaces are 
used to augment the schema information, by mappmg database metadata objects in 
different database schemas to different XML namespaces. 

Techniques are provided for modeUng XML data using an abstract data type in a 
relational database system. 

A mechanism is provided to generate a database query baised on an XML query 
and the mapping information when a user submits the XML query to access the data in 
tiie XML docmnent that is stored in the relational database. This process involves 

-3- 
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rewriting the user queries (and other data manipulation operations) into other queries that 
better exploit the underlying storage representation of the XML data, 

BRIEF DESCRIPTION OF THE DRAWINGS 

The present invention is illustrated by way of example, and not by way of 
limitation, in the figures of the accompanying drawings and in which Uke reference 
numerals refer to similar elements and in which: 

FIG. lA is a block diagram that illustrates schemas and schema objects in a 
relational database; 

FIG. IB is a block diagram that illustrates tables stored in a relational database; 
FIG. 2A is a block diagram that illustrates a hierarchy of Uritypes; 
FIG. 2B is a block diagram that illustrates a relational database table that stores 
Uritypedata; 

FIG. 3 A is a block diagram that illustrates a table; 

FIG. 3B is a block diagram that illustrates a view that contains a SQL result set; 
FIG. 4 is a block diagram that illustrates an XMLType storage architecture; 
FIG. 5 is a block diagram that illustrates the structure of an XMLType column; 

and 

FIG. 6 depicts a computer upon which embodiments of the invention may be 
implemented. 

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT 

Techniques are provided for using XML syntax for accessing data in relational 
databases, for moping data and metadata from relational databases to XML, for 
modeling XML data using an abstract data type in a relational database system, for 
multiple storage representations, for unifonn query interface, and for optimal processing 
using query rewrites. In the following description, for the purposes of explanation, 
numerous specific details are set forth in order to provide a thorough understanding of the 
present invention. It will be apparent, however, to one skilled in the art that the present 
invention may be practiced without these specific details. In other instances, well-known 
structures and devices are shown in block diagram form in order to avoid unnecessarily 
obscuring the present invention. 
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FUNCTIONAL OVERVIEW 
Using the techniques described, herein, any particular user of the relational 
database, herein referred to as the "current user", can visualize as an XML tree all the 
tables and views and the associated schema, in. the relational database, to which the 
current user has been granted access privileges. In other words, the user, instead of 
seeing the database data in the form of tables and views, the data is presented to the user 
in the form of an XML document, and the typical structure of an XML document is a tree. 

There may be several concurrent current users of the database. However, for the 
purpose of simplifying the description, the techniques described herein refer to a single 
current user. The XML tree is hereafter referred to as a "visualized XML document". 
The visualized XML document coniprises XML representations of the tables and views 
and the associated schema. Because the XML document is based on the access rights of a 
user, the XML document will vary from user to user based on each user's access rights. 
Thus, tbe visualized XML document, as described herein, is associated with the current 
user. 

The data items that are identified by a URL or URI, and that are to be accessed in 
a relational database, are referred to herein as "target data". Target data may vary from 
implementation to implementation. Target data may be any one of numerous types of 
data, such as relational database schema objects, relational data, control files, etc. The 
present invention is not limited to target data of any particular type. 

In order for the current user to access and manipulate target data in the relational 
databases as if the target data are XML data, a mechanism is provided for: 1) defining a 
default virtual visualization of any relational database for the current user, including aU of 
the data for which the current user has access privileges in the relational database, 
wherein the default virtual visualization is defined as a canonical XML document, 2) 
providing a standard Uniform Resource Indicator (URI) that is locally defined within tibie 
database and by which one or more fragments of the visualized XML document can be 
accessed by defining the URI as an XPath expression over the visualized XML document, 
3) providing a standard Uniform Resource Locator (URL) as a mechanism that can be 
used in conjunction with a web browser that is external to the relational database for 
accessing data stored in the relational database by defining the URL as an Xpath 
expression over the visualized XML document, 4) providing, in the relational database, 
new data types and new object types that can be used for storing the URIs and URLs, and 
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5) providing a mechanism to modify, oreate, add or delete data in the relational database 
through the visualized document, using the standard URIs and URLs as described herein. 

XPath expressions are W3c standard ways of navigating XML documents. XPath 
expressions allow for traversals and insert/deletes/updates on the visualized XML 
document (the XML visualization of the relational database). The XPath expressions can 
be converted into SQL Data Definition Language (DDL) and Data Manipulation 
Language (DML) commands in the relational database. 

The combination of (1) XML visuahzation of the relational database, and (2) the 
mechanism for navigating through the visualized XML document using XPath 
expressions, allows the user to '*point to" any data in the relational database. For 
example, an XPath expression such as, /SCOTT/EMP/ROW[EMPNC)=2100] points to the 
data value in the row identijfied by EMPNO =21 . The row in question is in a relational 
database table called EMP, which is a schema object of the relational database schema 
called Scott. The XML visualization of the relational database is described in greater 
detail herein. 

The results of a database query is herein referred to as a "SQL result set". When 
the SQL result set is converted into one or more XML documents, the converted result set 
is herein referred to as an "XML result set". The data in the relational database is herein 
referred to as "object relational data" and metadata that is associated with the object 
relational data is herein referred to as relational database schemas. A relational database 
schema is a collection of objects, herein referred to as "schema objects". Schema objects 
are logical structures that directly refer to the data in the relational database. Thus, 
schema objects include structures such as tables, viewsj clusters, indexes, etc. 

In order that users may sulMnit a query using relational database query language 
and receive a result set in the form of XML documents, amechanism is provided for: 1) 
Mapping of object relational data from the relational database to XML form; 2) Mapping 
of the relational database schemas to XML form; 3) Generating XML documents from 
the object relational data and the relational database schemas. 

The mechanism for generating XML documents as the result set from object 
relational data and relational database schemas is based on a set of rules stored in the 
relational database. Object relational data, either pre-defined or dynamically defined 
during the processing of the database query, are mapped to corresponding XML data 
based on the set of rules. Such a mapping is horein referred to as "canonical mapping of 
object relational data to XML form". 
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Similarly, relational database schemas are mapped to XML fonn by mapping the 
relational database schemas to their corresponding XML-Schemas, Such a mapping is 
based on a set of rules that are herein referred to as "canonical mapping of relational 
database schemas to XMI^schemas." The canonical mq)ping of relational database 
schemas to XML-schemas is described in greater detail herein. 

Further, generating an XML result set, i.e., generating XML documents ftom the 
SQL result set is based on a set of rules, as described in greater detail herein. 

In order to integrate the handling of XML data and SQL data in a relational 
database, a mechanism is provided to support an XML type datatype in the relational 
database for storing XML documents within columns and rows of tables. The storage 
representation may vary from implementation to implementation, The present invention 
is not limited to any particular storage representation. In certain embodiments of the 
invention, the user may submit an XML document for storage in the relational database. 
The data from each field of the XML docimient is automatically stored in the relational 
database in a manner that leverages various existing indexing mechanisms associated 
with storage. For example, when an XML document is submitted for storage in the 
relational database, a mechanism is provided to determine the corresponding storage 
column in the relational database for storing each field of the XML document. Thus, 
each field of the XML document is mapped to some column in the relational database and 
this mapping information is stored in the relational database. Dependrag on the type of 
data, some of the fields of data maybe lumped together for storage in a single object 
relational column while other fields maybe stored as separate object relational columns. 
The data from each field of XML document can be;indexed using an appropriate indexing 
scheme. For example, a B-tree index may be used for columns that contain relational 
type data and a text index, such as interMedia text, may be used for columns that contain 
large text data. In certain embodiments, the user may specify the mapping information. 
By specifying the mapping information, the user may control the granularity of the 
mapping. 

Thus, techniques are provided for 1) the uniform handlmg of XML data and SQL 
data, 2) a uniform query interfece for a well-defined set of XML operations, where the set 
of operations are decoupled from the underlying storage mechanism for the XML data in 
the relational database, 3) query rewrites into a form tiiat leverages the data access and 
data manipulation capabilities of the underlying storage mechanism in the relational 
database. 
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VIRTUAL XML VISUALIZATION OF A RELATIONAL DATABASE AND 
XPATH 

According to certain embodiments, the current user can see all the data in the 
relational database, to which the user has been granted access privileges, as a visualized 
XML document. The visualized XML document includes a "database tag" and a set of 
schemas with tables and views. For example, if the database is called "oradb" then the 
XML document starts with the database tag "<oradb>" and ends with the databse tag 
"</oradb>". 

The current user is permitted to read, insert, update and delete elements from the 
visualized XML document. The current user is thus unaware of the actual nature of the 
storage or access of the data in the relational database. The current user simply uses 
XPath expressions for navigation through the visualized XML document. 

For example, assume that the current user of ttie relational database is Scott. 
Associated with each current user of the relational database is a schema by the same 
name. A schema is a logical collection of relational database objects such as tables, 
views clusters, functions, etc. 

FIG. 1 A is a block diagram that illustrates schemas and schema objects in a 
relational database. Colunm 102 of FIG. 1 A contains a list of schema objects. For the 
purpose of explanation, only two schemas, SCOTT and JONES, are shown. Column 104 
contains the relational database objects in each schema. . For the purpose of explanation, 
only two tables, EMP and DEPT, are shown. Schema SCOTT contains table BMP and 
schema JONES contains table DEPT. 

FIG. IB is a block diagram that illustrates tables stored in a relational database. 
Relational database 1 10 contains tables, EMP and DEPT. Table EMP has 3 columns, 
EMPNO, ENAME and SALARY. Each colunm of EMP contains rows of values. Table 
DEPT has 2 columns, DEPTNO and DNAME. Each column of DEPT contains rows of 
values. 

Assume that the current user, Scott, has privileges to access schemas SCOTT and 
JONES in the relational database and has privileges to access the data associated with 
SCOTT and JONES. According to certain embodiments of the techniques, the current 
user, Scott, is able to see a default virtual visualization of the relational database as 
follows (not the full visualization): 
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<oradb> 
<SCOTT> 
<EMP> 
<ROW> 

<EMPNO>21</EMPNO> 
<ENAME>John<;^AME> 
<SALARY>100,000<^SALARY> 
</ROW> 
<ROW> 

.... <!- other etsp values ~> 
</ROW> 

</EMP> 
.... <!- other tables.. -> 
</SCOTT> 
<JONES> 
<DEPT> 
<ROW> 

<DEPTN0>1<DEPTN0> 
<DNAME>Marketiiig</DNAME> 
</ROW> 
<ROW> 

.... <!- other dept values -> 
</ROW> 
<yDEPT> 
</JONES> 
</oradb> 



The above default virtual visualization is merely an example of one 
implementation of a default virtual visualization. The defimlt virtual visualization may 
vary from implementation to implementation. The invention is not restricted to a 
particular visualization model. 

According to certain embodiments of the tephniquesj a standard URL and URI 
mechanism is also provided to access the data stored in any database, by defiboing the 
URL and URI as an XPath expression over the visualized XML document. 

According to one embodiment of the invention, the URL may be processed by 
using a servlet, which uses the native URI processing mechanisms to access the data 
pointed by the URL. 

According to certain embodiments of the invention, the database tag (oradb) may 
be implicitly bound in the processing context and need not be explicitly specified in the 



A current user who does not have local access to the relational database may use a 
browser to access data in the relational database over tiie Intemet by using a URL. For 
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example, assume that the current user is Scott and tiiat Scott would like to use a browser 
to access the employee-name column of EMP table at the row for which the employee 
number is 2100, and where the EMP table is in schema SCOTT. The URL that Scott 
would use may look like the foUowiug: 

http://machine-name/servlet-name/SCOTT/EMP/ROW[EMPNO=2100]/ENAME 
In the above URL, the database tag, "oradb", is implicitly bound, and thus the user 
need not specify the database tag in the URL. 

The result of accessing the URL or the URI would be a fragment of the visualized 
XML document containing the ename argument as shown below: 

<? xml version- '1.0" ?> 
<ENAME> John</ENAME> 

The current user can augment the URL or URI with content types to specify the 
Multipurpose Intemet Mail Extensions (MIME) type of the output. For example, if the 
URL points to a BLOB (Binary Large OBject) column that is storing an image, wherein 
the image is the "target data", then the content type can be set to gif Thus, in response to 
using the URL, the current user obtains the image rather than, for example, a large 
hexadecimal file. 

As another example, the current user may augment the URL to request, as the 
target data, the text value of the column to which the UKL points. For example, assume 
that the current user, Scott, uses the foUoAving URL to access the employee-name column 
of EMP table at the row for which the employee number is 2100: 

http://machine-name/<servlet-name>/ 
/SCOTT/EMP/ROW[EMPNO=2100]/ENAME/textO 

"textO" is an XPath standard to identify the text node. The use of textQ in the 
above URL would produce a result that contains only the text value in the employee- 
name column of EMP table at the row for which the employee number is 2100. The text 
value in the employee-name colunm of EMP table at the row for which the employee 
number is 2100 is "John". Thus, the result of accessing the above URL using textQ is 
"John". In contrast, when textQ is not used in the URL to access the employee-name 
column in the example, "John" is inlined inside a fragment of the visualized XML 
document as follows: 

-10- 
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<ENAME> John</ENAME> 



In anotiier embodimeat of the invention, the mime information may be derived 
automatically by the database, based on other auxiliary information that may be stored 
with the URL or through user written functions. 

MAPPING RULES FOR DEFINING VIRTUAL XML VISUALIZATION OF A 
RELATIONAL DATABASE 

Techniques are provided for defining the defeult virtual visualization of the 
database as a canonical XML document. According to one embodiment, the rules for 
defining the default virtual visualization are as follows: 

1) There is a pseudo top-level enclosing tag that identifies the relational database 
that contains the target data. An example of a pair of enclosing tags that identify the 
relational database that contains the target data is <oradb> . . .<yoradb>, where "oradb" is 
the name of the relational database that contains the target data, as shown below (not all 
the elements in the visualization are shown): 



<oradb> 

■ ■<SCOTT:i ■ ■■■ ■■ '■' 
<EMP> 
<ROW> 
<EMPN0>21</EMPN0> 
<ENAME>John</ENAME> 
<SALARY>1 00,000</SALARY> 
<ROW> 

</EMP> 

....<!- other tables^. ~> 
<ySCOTT> 
<JONES> 
<DEPT> 
<R0W> 

....<!- other dept values -> 
</ROW> 
<yDEPT> 
</JONES> 
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2) Each schema in the relational database for which the current user has been 
granted access privileges corresponds to one element in the visualized XML document. 
The name of the element is the same as the name of the schema to which the element 
corresponds. la the example illustrated herein, the schema SCOTT in the relational 
database "oradb" is represented by the element with the same name in the visualized 
XML document. Similarly, the schema JONES is represented by the element with the 
same name in the visualized XML document. The following visuaHzed XML document 
is a visuaUzation of the relational database down to the schema element level. For the 
purpose of illustration, only the elements corresponding to schemas SCOTT and JONES 
are shown. 



<oradb> 
<SCOTT> 
</SCOTT> 
<JONES> 
</JONES> 
</oradb> 



3) Each table or view in the relational database for which the current user has been 
granted access privileges corresponds to one element in the visualized XML docimient. 
The name of the element is the same as the name of the table or view to which the 
element corresponds. In the example illustrated herein, the table BMP in the relational 
database "oradb" is represented by the element with the same name in the visualized 
XML document. Similarly, the table DEPT is represented by the element with the same 
name in the visualized XML document. The following visualized XML document is a 
visualization of the relational database down to the table element level. For the purpose 
of illustration, only the elements corresponding to tables EMP and DEPT are shown. 



<oradb> 
<SCOTT> 
<EMP> 
</EMP> 
</SCOTT> 
<JONES> 
<DEPT> 
<;©EPT> 
<yjONBS> 
</oradb> 



-12- 
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4) Each row of each table or view in the relational database for which the crarent 
user has been granted access privileges corresponds to one element ra the visualized 
XML document. The following visualized XML document is a visuahzation of the 
relational database down to the row element level. For the purpose of illustration, only 
the elements corresponding to rows of tables EMP and DEPT are shown. 



<oradb> 
<SCOTT> 
<EMP> 
<ROW> 
</ROW> 

. . . <! — multiple ROW tag pairs - each pair corresponding to a single 

</EMP> 
</SCOTT> 
<JONES> 
<DEPT> 
<ROW> 
</ROW> 

. . . <! — ^multiple ROW tag pairs - each pair corresponding to a single 

</DEPT> 
<nONE&> 
</oradb> 



5) Each colunm of each table or view in the relational database for which the 
current user has been granted access privileges corresponds to one element in the 
visualized XML document. The name of the element is the same as the name of the 
colunm to which the element corresponds, hi the example illustrated herein, the colunm 
EMPNO in table BMP is represented by the element with the same name in the visualized 
XML document. Similarly, the colimin ENAME is represented by the element with the 
same name in the visuaUzed XML document. The following visualized XML document 
is a visualization of the relational database down to the column element level. For the 
purpose of illustration, only the elements corresponding to columns EMPNO and 
ENAME in table EMP are shown. 
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<oradb> 
<SCOTT> 
<EMP> 
<ROW> 
<EMPN0>21 00</EMPNO> 
<ENAME>JOHN<yENAME> 
<SALARY>100000<SALARY> 
</ROW> 
<ROW> 
<EMPNO>2200<EMPNO> 
<ENAME>TOM</ENAME> 
<SALARY>35000</SALARY> 
</ROW> 
.... <! — other rows. .> 
<fEMP> 
</SCOTT> 
<JONES> 
<DEPT> 
<ROW> 

<DEPTNO>l</DEPTNO> 
<DNAME>MARKETING</DNAME> 
</ROW> 

...<! — other rows., > 
</DEPT> 

</j6nes> 

</oradb> 

RULES FOR CONVERTING XPATH EXPRESSIONS INTO RELATIONAL 
DATABASE QUERIES 

According to one embodiment of the inveation, the Xpath query over the XML 
visualization may be translated into relational database queries and the result formatted in 
XML. Techniques are provided for converting XPath expressions into relational database 
queries. For the purpose of explanation, assume that the XPath expression that is to be 
converted into a query is in the context of the relational database "oradb". Thus, the 
format of a typical XPath expression is the context of "oradb" can be generalized as 
follows: 

/Schema/Table/Row/Column/Attribute ...(! fbrther attributes) 
Each element of the above XPalh expression may optionally have a predicate. 
Predicates take the form, 

[(element) (operator) (value)] 

For example, the element, Row, may have a predicate as follows, 
/Schema/Table/Row [Columnl = 2100]/Colmim2 
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The rules for converting XPath ejqpressions into relational database queries wiU 
rejfer to the above general format for an XPath expression and are as follows: 

1) An XPath expression of the form /Schema/Table is converted to a 
corresponding relational database query such as the following SQL statement. 

Select * 

From Schema.Table 

The syntax used in the preceding statement is merely illustrative. The actual 
syntax of SQL statements may vary firom implementation to implementation. The present 
invention is not limited to any particular syntax. 

The results of tiie SQL statement can then be converted into a corresponding 
fragment of the visualized XML document. 

2) An XPath expression of the form /Schema/Table/Row/Column is converted to a 
corresponding relational database query such as the following SQL statement. 

Select Column 
From Schema^Table 

The syntax used in the preceding statement is merely illustrative. The actual 
syntax of SQL statements may vary from implementation to implementation. The present 
invention is not limited to any particular syntax. 

The results of the SQL statement can then be converted into a corresponding 
fragment of the visualized XML document 

3) An XPath expression of the form /Schema/Table/Row [Empno = 21 00]/Column 
is converted to a corresponding relational database query such as the following SQL 
statement. 

Select Column2 
From Schema.Table 
Where Columnl = 2100 

The syntax used in the preceding statements is merely illustrative. The actual 
syntax of the query language statements may vary from implementation to 
implementation. The present invention is not limited to any particular syntax. 
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The results of the query language statement can thai be converted into a 
corresponding fragment of the visualized XML document. 
URI TYPES 

According to certain embodiments, a special data type is provided in the relational 
database for storing URIs and URLs in the relational database. Such a data type is herein 
referred to as an "Uritype". URIs and URLs can be stored in columns in relational 
database tables by defining the URIs and URLs as Uritype data. 

FIG. 2A is a block diagram that illustrates a hierarchy of Uritypes. FIG. 2A 
shows a general Uritype 210 that comprises subtypes. According to certain embodiments, 
the subtypes are DB-Uritype 212, HTTP-Uritype 214, and FTP-Uritype 216. 

The HTTP-Urilype stores HTTP (HyperText Transfer Protocol) URLs, and 
fetches the data pointed to by the URL using the HTTP protocol. The FTP-Uritype stores 
FTP (File Transfer Protocols) URLs and fetches the data, using FTP. The DB-Uritype 
stores intra-database references using the Xpath mechanism described herein. 

The DB-Uritype can fetch the data associated with the URL using the Xpath 
translation mechanism defined earlier or through other mechanisms. 

The user may define subtypes of the Uritype or any of the other subtypes, and 
provide the implementation for getting the data pomted to by that URL. 

Apart from bemg able to store URIs and URLs, the general fimctions associated 
with the Uritype data type include retrieving URIs and URLs as well as retrieving XML 
documents that are stored as LOBs, for example, CLOBs and BLOBs, in the relational 
database. 

When the current user wishes to retrieve target data, pointed to by the URL, from 
the relational database, the current user's XPatibi expressions are automatically converted 
into appropriate query language statements. The actual syntax of such statements depend 
on the query language used in the relational database and may vary from implementation 
to implementation. The present invention is not limited to any particular syntax. The 
relational database functions of the Uritype data type can be abstracted by the following 
statements: 

getURLO; 
getBLOBO; 
getCLOBQ. 
getXMLO; 
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The preceding statements merely illustrate function. Such statements are not 
necessarily query language statements. The ravention is not restricted to a particular set 
of query language statements. 

FIG. 2B is a block diagram that illustrates a relational database table that stores 
Uritype data. Relational database table 200 is a Purchase Order table. Table 200 has 2 
colmims: Purchase Order Number column 250 and Purchase Order Link coluron 260. 
Both columns 250 and 260 contain 3 rows of data, namely, row 271, row 272 and row 
273. The Purchase Order Link column can store data of type UriType. 

Column 260 at row 271 stores data of type HTTP-Uritype. Column 260 at row 
272 stores data of type FTP-Uritype. Finally, column 260 at row 273 stores data of type 
DB-Uritype. Note that since the DB-Uritype, HTTP-Uritype etc., have been defined as 
subtypes of the UriType type, we can store instances of these types in the Purchase Order 
Linkcolunm. 

The current user can retrieve any of the data pomted by the Uritype data stored in 
table 200 The database will automatically fetch the data using the appropriate 
mechamsms. 

For example, the queiy shown below, retrieves the Purchase Order data pointed to 
by the Purchase Order Link column: 

Select p.PurchaseOrderLink.getXML0 
From PurchaseOrdeiTable p; 

The database will fetch the purchase order through HTTP for the first row, use 
FTP for the second row and use the DB-Uritype processing mechanism for the last row. 

The syntax used in the preceding statements is merely illustrative. The actual 
sjoitax may vary fi-om implementation to implementation. The present invention is not 
limited to any particular syntax. The conversion into the appropriate query is transparent 
to the current user. Thus, it is not necessary for the current user to be aware of the type of 
the target data. 

MODIFYING RELATIONAL DATA USING URITYPE FUNCTIONS 
According to certain embodiments, a mechanism is provided to modify, add or 

delete XML data that is stored in the relational database using the standard URIs and 

URLs as described herein. 
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For example, assume that the cmrentusra:, Scott, is able to see a default virtual, 
visualization of the relational database as follows (not the full visualization): 



<bradb> 
<SCOTT> 
<EMP> 
<ROW> 

<EMPN0>2 l</EMPNO> 
<ENAME>Jolm</ENAME> 
<SALARY>1 00,000</SALARY> 
</ROW> 
<ROW> 

....<!- other emp values -> 

<mow> 

</EMP> 
....<!- other tables.. -> 
</SCOTT> 
<JONES> 
<DEPT> 
<ROW> 

<DEPTN0>1</DEPTN0> 
<DNAME>Marketing</DNAME> 
</ROW> 
<ROW> 

.... <!- other dept values -> 

</ROW> ■ ■■ ■ '■■ - 

</DEPT> 
</JONES> 
</oradb> 



Further assume that the current user, Scott, would ILke to update data at the 
employee-name column of EMP table at the row for which the employee number is 2100. 
The update comprises changing the name "John" to "Mary". 

According to certain embodiments, if the current user, Scott, has direct access to 
the relational database, then Scott can perform the foUowing: 1) selects the update 
operation for updating XML data and 2) uses the following XPath expressions: 



/SCOTT/EMP/ROW[EMPNO=2100]/ENAME 
<ENAME>Mary</ENAME> 



The XPath expression /SCOTT/EMP/ROW[EMPNO=2100]/ENAME indicates 
the row and colimm of the target data that is to be updated. 
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The XPath expression <ENAME>Maiy</ENAME> indicates the new value of the 
target data to be updated. 

The above XPath expressions are converted into query language statements such 

as: 

UPDATE "SCOTT"."EMP" 
SET "ENAME" = 'Mary' 
Where "EMPNO" = 2100; 

If the current user, Scott, is using a web browser to access target data in the 
relational database, then according to certain embodiments, a general purpose servlet may 
be provided to allow the current user to modify, add or delete XML data that is stored in 
the relational database using the standard URb and URLs. Using the above example of 
updating the name "John" to "Mary", a general purpose servlet is provided that dlows 
Scott to perform the following: 1) select the update operation for updating XML data and 
2) post to the servlet the "update" mformation m the form of the following XPath 
expressions: 

/SCOTT/EMP/ROW[EMPNO=2100]/ENAME 
<ENAME>Mary</ENAME> 

According to certain other embodiments, a special servlet may be provided for 
each database operation. Li other words, there may be an "Insert-servlef ' for the INSERT 
operation, a "Delete-servlet" for the DELETE operation, and an "Update-servlet" for the 
UPDATE operation. 

Using the above example of updating the name "John" to "Mary", aa 
"hisert_servlet" is provided that allows Scott to perform the following: 1) select the 
update operation for updating XML data and 2) post to the servlet the "update" 
information in the form of the following XPath expressions: 

http://machine-name/<update- 
servlet>/SCOTT/EMP/ROW[EMPNO=2100]/ENAME 
<ElSrAME>Mary</ENAME> 

The same mechanism is used to modify, add or delete metadata. For example, if 
the current user, Scott would hke to delete the schema SCOTT, then Scott can perform 
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the following: 1) selects the delete operation for deleting XML data in the relational 
database and 2) uses the following XPath expression that indicates which level in the 
visualized XML document to delete: 

http://machine-name/<delete-servlet>/ SCOTT 
XML RESULT SET FROM SQL RESULT SET 

FIG. 3 A is a block diagram that illustrates a table that is stored in a relational 
database. Table BMP has 3 columns, EMPNO, ENAME and SALARY. Each column of 
EMP contains a value for each of a plurality of rows of table BMP. However, for 
simpUcity, FIG. 3A shoWs only 2 rows, namely, row 302 and row 304. In column 
EMPNO, row 302 contains the value "2100" and row 304 contains the value "2200". 
Similarly, in column ENAME, row 302 contains the value "JOHN" and row 304 contains 
the value "MARY". In colunm SALARY, row 302 contains the value "55K" and row 
304 contains the value "65K". 

As an example, assume that a user submits a relational database query to retrieve 
values from two of the columns, namely, EMPNO and ENAME from table EMP, An 
e{xample of the relational database query is the following SQL statement, 

SELECT empno, ename FROM emp 

The syntax used ia the preceding statement is merely illustrative. The actual 
syntax of SQL statements may vary from implementation to implementation. The present 
invention is not limited to any particular syntax. 

FIG. 3B is a block diagram that illusfrates a view that contains the SQL result set 
of the SQL statement, SELECT empno, ename FROM emp. The SQL result set 
comprises only two of columns of table EMP. Thus, FIG. 3B shows only columns 
EMPNO and ENAME. Even though the SQL result set comprises all the rows of value in 
columns EMPNO and ENAME, for simplicity, only rows 310 and 312 (which 
respectively contain values from rows 302 and 304) are shown in FIG. 3B. 

The SQL result set of FIG. 3B can be converted into a corresponding XML result 
set based on the following rules, according to certain embodiments of the invention: 

1) The XML result set is in the form of an XML document that begins with a 
ROWSET tag. The ROWSET tag indicates that the XML document comprises a set of 
row elements. 



-20- 



wo 02/21339 



PCT/USOl/28180 



2) Each row of the SQL result set is converted to a corresponding ROW element 
in the XML document where the ROW element is indicated by a pair of ROW tags. 

3) Each column within a given row of the SQL result set is converted to a 
corresponding COLUMN element that is embedded in the encompassing ROW element 
that in turn corresponds to the given row of the SQL result set. The name of the 
COLUMN tag is the name of the correspondiag colunm in the SQL result set. 

The ROWSET, and ROW tags may have varying monikers in various 
implementations of the invention. The present invention is not limited to any particular 
moniker for such tags. As for COLUMN tags, according to one embodiment, an aliasing 
mechanism is provided for changing names of the COLUMN tags. 

To illustrate, the XML result set of the above example may appear Uke the 
following: 

<ROWSE'I^ 
<ROW> 

<EMPNO>2100<BMPN0> 
<ENAME>John</ENAME> 
</ROW> 

<EMPNO>2200</EMPNO> 
<ENAME>Mary<ENAME> 
<ROW> 

....<!- other column elements ~> 
</ROW> 
...<!- other row elements -> 
<ROWSE'I> 

MAPPING OF OBJECT RELATIONAL DATA 

An example of the canonical mapping of object relational data to XML form is as 



a) The mapping of object relational columns to XML elements: 
For exanqjle, referring to FIG. 3 A, the XML result set of a SQL query to select 
EMPNO and ENAME at the single row 302 would appear like the following: 



<ROWSET> 
<ROW> 

<EMPN0>2100<^MPN0> 
<ENAME>John</ENAME> 
<ROW> 
</ROWSET> 
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"Eie object relational columns EMPNO and ENAME are mapped to corresponding 
COLUMN elements in the XML result set. EMPNO and ENAME are embedded in the 
encompassing ROW element. 

b) The m^ing of object relational object types to XML elements with nested 
sub-elements containing the attributes of the object type: 

For the purpose of explanation, assume that a user-defined type called 
"AddressJ" is previously created in the relational database. "AddTess_t" is a complex 
object type that comprises 3 scalar attributes, namely CITY, STATE and ZIP. Assume 
that there is a table in the relational database called Employee_table. Employeejable has 
2 columns ENAME and ADDRESS. ENAME is of type "string" and ADDRESS is the 
user-defined type "Address_t". Further assume that columns ENAME and ADDRESS 
each contain only a single row of value, namely, employee name "John" and John's 
address, respectively. 

A SQL query such as "SELECT * FROM Employee_table" can produce a SQL 
result set that maps to the following XML result set, according to certain embodiments of 
the invention: 

<ROWSET> 
<ROW> 
<ENAME>John</ENAME> 
<ADDRESS> 

<CITY>Redwood City<;/CrrY> 
<STATE>Califomia</STATE> 
<ZIP>94065<;/ZIP> 
<ADDRESS> 
<ROW> 
</ROWSET> 

The object relational column ADDRESS maps to an element with the same tag 
name in the XML result set. The element ADDRESS, which is of type "addressj", has 
attributes CITY, STATE and ZIP that are mapped to sub-elements of the element 
ADDRESS. Each sub-element has the name of the attribute as its corresponding tag 
name in the XML result set. 

c) The mapping of object relational collection types to XML lists: 
For the pmpose of explanation, assume that a user-defined type called 

"Lineitems_t" is previously created in the relational databsae. "LineitemsJ;" is a 
collection object type that comprises a plurality of collection items. Each collection item 
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has an ID attribute that defines the positional value of the item within the collection. For 
example, assume that there is a table in the relational database called 
PurchaseOrder_table. PurchaseOrder table has 2 columns PONO for purchase order 
number and LINEITEMS for a Ust of line-items. PONO is of type "number" and 
LINErrEMS is of type "Litieitems_t". Further assume that columns PONO and 
LINEITEMS each contain a single row of value, namely, pxurchase order number "101" 
and the collection of lineitems that is associated with purchase order number "101". 
Assume that there is 1 item, namely, "books", in the collection of lineitems. 

A SQL query such as "SELECT * FROM PurchaseOrderJable" produces a SQL 
result set that maps to the following XML result set: 

<ROWSET> 
<ROW> 
<PONO>101</PONO> 
<LINEITEMS> 
<LINEITEMS_Tid = "l"> 

<LINEITEMNAME>BOOKS<yLINErrEMNAME> 
<COST>$150</COST> 
</L[NIErrEMS_T> 
</LINEITEMS> 
</ROW> 
</ROWSET> 

The object relational column LINEITEMS maps to an element with the same tag 
name in the XML result set. Each collection item in LINEITEMS is mapped to a sub- 
element that is embedded within the LENEITEMS element. Each collection item has the 
collection type name as the tag name, namely, "LI1SIEITEM_T". Each collection item has 
attributes LINEITEMNAME, and COST that are mapped to sub-elements that are 
embedded within the element LINEITEM_T. Each sub-element has the name of the 
attribute as its corresponding tag name, e.g., <LINEITEMNAME>, and <COST>. 
d) The mappmg of object relational REF types to URI references: 
Object relational REF columns are columns for storing object references to row 
objects contained in any object relational table. For the purpose of explanation, assume 
that the relational database has a table called Employee_table. Employeejtable has 
columns EMPTNO, ENAME and DEPTREF. EMPNO is of type "number" and assume 
that EMPNO has only one row of value "15". ENAME is of type "string" and assume 
that ENAME has only one row of value "John". DEPTREF is of type "BEF' and assume 
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that DEPTREF has only one row of value, which is a reference to a row of value 
corresponding to DEPTNO = 1001 in another table called Department_table. Assume 
that Departmentjable is in the schema SCOTT and has colunms DEPTNO with value 
"1001" and DEPTNAME with value "SPORTS". 

A SQL query such as "SELECT EMPNO, DEPTREF FROM Employee-table 
produces a SQL result set that maps to the following XML result set: 

<ROWSET> 
<ROW> 
<EMPN0>15<EMPN0> 

<DEPTREF>0344855FF4ABBCC3333</DEPTREF> 
<ROW> 
</ROWSET> 

According to certain embodiments of the invention, the REF value in the 
DEPTEIEF column is converted to XML form for the XML result set by converting the 
object relational REF value into a binary value that is encoded in hexadecimal ("HEX"). 
Thus, in the above XML result set "0344855FF4ABBCC3333" is the encoded HEX. 

According to certain other embodiments of the invention, the REF value in the 
DEPTREF column is converted to XML form by converting the REF value into a 
Database Uniform, Resource Indicator ("DBURI") reference. DBURI references are 

described in detail in U.S. patent application serial number ■ , 

Attomey Docket No. 50277-1564, entitled "METHOD AND APPARATUS FOR XML 
VISUALIZATION OF A RELATIONAL DATABASE AND UNIVERSAL 
RESOURCE IDENTIFIERS TO DATABASE DATA AND METADATA," naming as 
inventors MuralidharKrishnaprasad, Viswanathan Krishnamurthy, Ravi Murthy. 

Using the same example above, the DBURI reference may appear as, 
SCOTT/DEPARTMENT_TABLE/ROW[DEPTNO= "1001"], where Deptno is the 
primary key information. Thus, the XML result set may appear as: 

<ROWSET> 
<ROW> 
<EMPNO>l 5</EMPNO> 

<©EPTREF>/SCOTT/DEPARTMENT_TABLE/ROW[DEPTNO="1001"]</DEPTREF> 
</ROW> 
<ROWSET> 
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According to yet other embodiments of the invention, an object identifier that 
uniquely identifies the object stored in the REF colxrain can be used in creating the 
DBURI reference. Using the same example above, the DBURI reference may appear as, 
SCOTT/DEPARTMENT_TABLE/ROW[SYS_NC_OID$="0asfgd23gfm3423n"] 

Thus, the XML result set may £^pear as: 

<R0WSE1> 
<ROW> 

<EMPN0>1 5</EMPN0> 

<DEPTREF>/Scott/Department_Table/Row[SYS_NC_Oro$="0asfgd23gfci3423n"]<^^ 
> 

<ROW> 
<ROWSET> 

According to an embodiment of the invention, LOB values may be converted to 
DBUri references as well. For example, if there is a column in the department table called 
DEPTJPHOTO, which is a BLOB column, then a DBUri reference can be used to 
reference the BLOB data instead of in-lining the BLOB data in the XML document. 

The XML result may appear as follows for the DEPT_PHOTO column: 

<ROWSET> 
<ROW> 
<DEPTN[O>1001<VDEPTNO> 

<DEPT_PHOTO>/SCOTT/DEPARTMENT_TABLE/ROW[DEPTNO=1001]/ 
DEPT_PHOTO/textO</DEPT_PHOTO> 

<ROW> 
<yROWSET> , 

The invention is not limited to generating DBUri references to LOBs and REFs. 
A DBUri reference can be generated to reference any piece of database data that need not 
be inlined in the visualized document. For example, nested tables, LONGs and other 
datatypes may be converted to DBUri references instead of inlining the whole data inside 
the visualized document. The DBUri reference can be generated by using the primary key 
information or ROWID of the row in the predicates of the Xpath expressioa 

MAPPING OF RELATIONAL DATABASE SCHEMAS 

Relational database schemas are mapped to XML form by mapping the relational 
database schemas to theur corresponding XML-Schemas. For example, referring to FIG. 
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3A, in order to produce the XML result set of a SQL query to select EMPNO and 
ENAME at the single row 302, an XML-Schema is generated. The XML-Schema defines 
the structure of the XML result set, which is in the form of an XML document. Thus, the 
XML-Schema that corresponds to the XML result set of a SQL query to select EMPNO 
and ENAME at the single row 302 is as follows, according to certain embodiments of the 
invention: 

<xsd:schema xmlns :xsd=" http://www. w3 .org/2000/1 Q/XMLSchema "> 
<xsd:element name^"ROWSET"> 
<xsd:complexType> 

<xsd:elemeat name="ROW" minOccurs="0" maxOccurs="unbounded"> 
<xsd:complexType> 

<xsd:element name-'EMPNO" type^"xsd:integer" minOccurs="0"/> 
<xsd: element name="ENAME" type="xsd:string" nullable="true" 
minOccurs="0"/> 

</xsd:complexType> 
</xsd:element> 
</xsd:complexType> ... . 
</xsd:element> 
<;/'xsd:schema> 

As can be seen from the above example, in addition to defining the structure 
of the XML result set (XML document), XML-Schemas also define the type of the data 
and constraints, if any, on the data. For example, the above sample XML-Schema 
indicates, among other things: 1) the URL, i.e., 

http://www.w3.org/2000/10/XMLSchema. for the namespace that defines the standards 
that apply to all XML-Schemas, 2) element ROWSET is of type "complex" and contains 
ROW elements, 3) the ROW elements are of type "complex" and can occur any number 
of times in the XML document, 3) the element EMPNO, which is embedded m the ROW 
element, is of type "integer", and 4) the element ENAME, winch is embedded in the 
ROW element, is of type "string". The nuUable attribute indicates whether the element 
value can be NULL or not. "MinOccurs" indicates the minimum number of occurrences 
of this element in the resultant document. 

Alternatively, XML-Schemas can be "inlined" in its corresponding XML result 
set (XML document). For example, referring to FIG. 3A, the XML result set of a SQL 
query to select EMPNO and ENAME at the single row 302, can have inlined in the XML 
result set its corresponding XML-Schema as follows, according to certain embodiments 
of the invention: 
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<?xml version = '1.0'?> 
<DOCUMENT xiiilns:xsd='' htto://www.w3.org/2000/10/XMLSchema ''> 
<xsd:schema xinlns:xsd='' http://www.w3.orey2000/10/XMLScliema ''> 
<xsd:element name="ROWSET"> 
<xsd:complexType> 

<xsd:element naine="ROW" mmOccurs-'O" maxOccuxs="unbounded"> 
<xsd: complexType> 

<xsd:elemeiit nameF="EMPNO" type="xsd:mteger" minOccurs="0"/> 
<xsd:elementnanie="ENAME" l3T)e="xsd:string" iiullable="tme" 
minOccxirs="0"/> 

</xsd:complexType> 
</xsd:element> 
</xsd:coinplexType> 
</xsd:element> 
</xsd:schema> 

<ROWSET xmliis:xsi=" http://ww.w3.org/2000/10/XMI^chema-iastance' ' 
xsi:noNamespaceSchemaIx)ca1ioii-'#/DOCnjME]Srr/xsd:scheana 
)]" 

<ROWnuni="l"> 
<EMPNO>2100<yEMPNO> 
<ENAME>JOHN</ENAME> 
</ROW> 
<yROWSET> 
</DOCUMENT> 



XML NAMESPACES 

Object relational data type definitions that are associated with a given relational 
database schema can be bound to a corresponding XML namespace. An XML 
namespace is a collection of names that are used in XML documents as element types and 
attribute names. An XML namespace can be defined by a URL. For example, as 
explained herein, assume that the relational database has a user-defined type "Address_t", 
which is a complex object type that comprises 3 scalar attributes, namely CITY, STATE 
and ZIP. Forthepurposeof explanation, assume that the complex object type, 
"Address_t", is defined in relational database schema SCOTT. Thus, "Address t" can be 
bound to the XML namespace that is defined by the URL, http://ora,com/SCOTT , for 
example. 

An XML-Schema can contain object relational types firom different XML 
namespaces. To illustrate, assume a relational database schema FOO and a relational 
database schema PEE is created. Further assume that the relational database schema FOO 
contains the user-defined, type called AddressType, and the relational database schema 
PEE contains the user-defined type called NameType. The AddressType comprises 3 
-27- 



wo 02/21339 



PCT/USOl/28180 



scalar attributes, namely CITY, STATE aad ZIP. The NameType comprises 2 scalar 
attributes, namely EERSTNAME and LASTNAME. Assume that an object relational 
table, EMP2, is created. EMP2 has 2 columns, namely ENAME and EADDR. ENAME 
contains the name of employee, "James Bond" and is of type NameType. EADDR 
contains the address of James Bond and is of type AddressType. 

The following SQL statements illustrate the creation of database schema FOO, 
database schema PEE,. AddressType, NameType and EMP2 in the relational database: 



connect sys/sys as sysdba 
grant resource,dba to foo identified by ball; 
grant resource,dba to pee identified by wee; 
grant execute any type to foo; 
grant execute any type to pee; 
connect foo/ball 

create type AddressType as object (street varchar2(30), city varchar2(30), zip 

number(5,0)); 

/ 

comiectpeeAvee 

create type NameType as object (FirstName varchar2(30), LasfName varchai2(30)); 

/ 

create table Emp2 
( 

ename NameType, 
eaddr foo. AddressType 

); 

The syntax used in the preceding statements is merely illustrative. The actual 
syntax of SQL statements inay vary from implementation to implementation. The present 
invention is not limited to any particular syntax. • 

In table EMP2, the column ENAME uses the NameType that is defined for 
relational database schema PEE while the column EADDR uses the Address Type that is 
defined for relational database schema FOO. 

Thus, the XML-Schema that corresponds to the XML result set of a SQL query 
such as SELECT * FROM EMP2 will contain separate URLs that define the XML 
namespace for FOO and for PEE. The XML namespace for FOO will contain the 
definition for AddressType. The XML namespace for PEE will contain the definition for 
NameType. 
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The XML-Schemas that correspond to the XML result set of a SQL query such as 
SELECT * FROM EMP2 are as follows, according to certain embodimaits of the 
invention: 



<xsd:schema xmlns:FOO=" http://ns.oracle.com/xdb/FOO " 
xm]ns:xsd='' http://www.w3.org/2000/10/XMLSchema '' 
xmhis:PEE=" http://ns.oracle.com/xdb/PEE "> 
<xsd:element nanie="ROWSET"> 
<xsd:complexType> 

<xsd:element name="ROW" minOccurs="0" maxOccurs="unbounded"> 
<xsd:complexType> 

<xsd:elementname="ENAMB" type="PEE:NAMETYPE" nullable="true" 
rrdnOccurs="0"/> 

<xsd:element nanie="EADDR" type="FOO:ADDRESSTYPE" 
nuUable-'true" niinOccurs="0"/> 
</xsd:complexType> 
</xsd:element> 
</xsd;coinplexType> 
</xsd:element> 
</xsd:schema> 

<schema targetNamespace=" http://ns.oracle.coni/xdb/FOO " 
xm]ns=" http w3 ■org/2000/1 0/XMLSchema " 

xmlns:FOO=" http://ns.oracle.com/xdb/FOO "> 
<complexType name="ADDRESSTYPE"> 

<element name-'STREET" type="string" nullable="true" minOccurs="0"/> 
<element name="CirY" type="string" nuUable-'true" minOccurs="0"/> 
<element name="ZIP" type="integer" nullable^"true" minOccurs="0"/> 
</complexType> 
</schema> 

<schema targBtNamespaoe=" http://ns.oracle.com/xdb/PEE " 
xmtos='' http://ww.w3.orfiy2000/10/XMLSchema '' 
xmlns:PEE=" http://ns.oracle.com/xdb/PEE "> 
<complexType name="NAMETYPE"> 

<elementiwmeF='TIRSTNAME" type="string" nullable="true" ininOccurs="0"/> 
<element name^'TLASTNAME" type^"string" nullable^"true" rtiinOccurs="0"/> 
\ . </complexType> 
</schema> 

Alternatively, XML-Schemas can be "inlined" in its corresponding XML result 
set that contains the target data, namely, the name and address of the employee in EMP2. 
According to certain embodiments of tihe invention, the XML result set shows its 
corresponding XML-schemas "inlined": 



<?xml version = '1 .0'?> 
<DOCUMENT xmhis:xsd=" httD://www.w3.org/2000/10/XMLSchema "> 
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<schema targetNamespace=" http://ns.oracle.com/x<ib/PEE" 
xmlns=" http://ww.w3 .org/2000/1 Q/XMLSchema " 
xmliis:PEE-" http://ns.oracle.com/xdb/PEE "> 
<complexType name="NAMETYPE"> 

<element name="FIRSTNAME" type-'string" nuUable-'true" minOccurs="0"/> 
<element name="LASTNAME" type-'string" nullable="true" ininOccurs="0"/> 
<complexType> 
</schema> 

<schema targetNatnespace=" http://ns.oracle.coni/xdb/FOO" 
xm]ns=" http://www.w3 .org/ZOOO/l 0/XMLSchema" 
xmlns:FOO=" http://'ns.oracle.com/xdb/POO "> 
<complexType name="ADDRESSTYPE"> 

<element name="STREET" type="string" nullable="trae" minOccurs="0"/> 
<element name-'CITY" type="string" nullable- 'true" minOccurs="0"/> 
<element name="ZIP" type="mteger" nullableF="tme" rmnOcciirs="0"> 
</complexTYpe> 
</scliema> 

<xsd: schema xmlns:FOQ=" http://ns.oracle.coni/xdb/FOO '' 
xmliLs:xsd=" http://www.w3 .org/2000/1 0/XMLSchema" 
xmkis:PEE=" http://ns.oracle.com/xdb/PEE "> 

<xsd:import targetNamespace=" http://ns.oracle.coin/xdb/PEE " 
schemaLbcation=''#/DOCUMENT/xsd:schema[@targetNamespace=M 
xdb/PEET /> 

<xsd:unport targetNamespace^" http://ns.oracIe.coin/xdb/POO " 
schemaLocation-'#/DOCUME]^/xsd:schema[@targetNamespace= 'http://ns. 
xdb/FOQ '1"/> 

<xsd:element name="ROWSET"> 
<xsd:complexType> 

<xsd:element name-'ROW" minOccms="0" maxOcciu-s="unbouiided"> 
<xsd:coniplexType> 

<xsd:elemeiit name="ENAME" type="PEE:NAMETYPE" nullable="true" 
minOccitrs="07> 

<xsd:elenient name="EADDR" type="FGO:ADDRESSTYPE" 
millable^''true''imnOcciirs=''0''/> 
</xsd:complexType> 
<^sd:element> 
</xsd: complexType> 
</xsd:element> 
</xsd:scliema> 

<ROWSET xrQli]s:xsi='' httD://ww.w3.ora^2000/10/XMLSchema-iiist^^ 
xsi:noNamespaceSchemaIx)catioiF=''#/DOCUMENT/xsd:schema[not(@t^^^ 

)]"> 

<ROWnum="l"> 
<ENAME> 

<FIRSTNAME>James</FIRSTNA]y[E> 

<LASTNAME>Bond<;/LAS'mAME> 
</ENAME> 
<EADDR> 

<STREET>00 secret ave</STREET> 

<CITY>London</CnY> 
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<ZIP>39281</ZIP> 
</EADDR> 
</ROW> 
</ROWSET> 
<;a)OCUMENT> 

UNIFORM HANDLING OF XML DATA AND SQL DATA 

Typically, in a relational database, there are pre-defined relational data types. 
Examples of typical pre-defined relational datatypes are number, date, string, etc. Object- 
relational databases may also contain user-defined object types. However, in order to 
provide uniform handling of XML data and SQL data, a datatype called XMLType is 
natively defined in the relational database system. The XMLType datatype can be used 
for storing any type of XML data, be it structured XML data or unstructured XML data. 

FIG. 4 is a block diagram fliat illustrates the XMLType storage architecture. 
Block 402 is XML data that is to be stored using the XMLType shown at block 406. The 
XMLType encapsulates the underlying storage mechanisms for XML data. Some of the 
storage mechanisms are shown in the storage layer 414. In storage layer 414 is shown a 
LOB storage mechanism 408, an object relational storage mechanism 410, and an "other" 
storage mechanism 412. "Other" storage mechanism 412 can be any appropriate storage 
mechanism for XML data. Thus, the storage mechanisms in storage layer 414 do not 
comprise the exhaustive set of storage mechanisms for XML data. Because the 
XMLType encapsulates the underlying storage mechanisms, a user of XML data only 
sees the XMLType while the actual details of the underlying storage mechanism of the 
XML data are hidden firom the user. Typically, an administrator of the relational database 
system chooses the underlying storage mechanism for the XML data that is to be stored. 
The adinimstrator chooses the type of underlying storage mechanism based on 
performance considerations of the storage mechanism. 

To illustrate storage, some of the fields of a given XML document may contain 
structured data. Structured data is data that is citable of being mapped to relational 
columns in the relational database. In another example, assume that the XML document 
contains the textual content of an entire book. Rather than exploding such an XML 
document by mapping every element or field of the XML document to a relational 
column, only fields that contain data that are likely to be queried by a user are mapped to 
pre-defined relation^ types, such as a string, number, etc, while the rest of the data may 
be lumped together and mapped to one column for Character Large Objects (CLOBs). A 
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user may create his or her own template to specify what fields are to be mapped to . . 
relational columns and what fields are to be mapped to CLOBs. 

FIG. 5 is a block diagram that illustrates the structure of an XMLType column. 
Column 504 is an XMLType column that contains an XML document that comprises 
structured data. The fields of the structured data are mapped into hidden columns 506. 
For example, the PONO element of the XML document is mapped to a NUMBER 
column, and PNAME is mapped to a string colimm. In FIG. 5, the crosshatched area 
indicates that the columns are hidden fi-om the user's view. The user only sees a single 
XMLType column. 

UNIFORM QUERY INTERFACE 

According to certain embodiments of the invention, a uniform query interface is 
provided in order to define a core set of operations on XMLType data that is stored in the 
relational database. Such operations are independent of the underlying storage format. 
According to certain embodiments of the invention, the operations on the XMLType data 
is functionally abstracted as follows: 

1) Extract fragments of a given XML document 

2) Test for existence of certain structures in the XML document 

3) Extract certain data values in the XML document 

4) Transforming a given XML document. The above list of operations is not an 
exhaustive list of operations for XMLType data. To illustrate some of the operations, 
assume that an XML document called "X" contains purchase order data. The purchase 
order data includes a purchase order numba: 'TONO" with value "21", purchase order 
name "PNAME" with value "JOHN" and a collection of hneitems and appears as 
follows: 

<P0> 
<PONO>21</PONO> 
<PNAME>JOHN</PNAME> 
<LINErrEM> 

<LINErrEMNO> 100 </LI]SIErrEMNO> 

</LINEITEM> 
<! Other lineitems > 

<ypo> 

Thus, according to certain embodiments of the invention, an example of the 
operation for extracting a firagment of XML docviment "X" is as follows: 
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EXTRACT (X, TO/LINEITEM') 

The above operation extracts a fragment of the document X, wherein the fragment 
is a sub tree comprising of all the branches under LINEITEM. 

An example of the operation for extracting certain data values in the XML 
document "X" is as follows: 

EXTRAGTVALUE (X, 'PO/PNAME') 

The above operation extracts the scalar value in PNAME, namely, "JOHN". 
An example of the operation for testing for the existence of certain elements in the 
XML document "X" is as follows: 

EXISTSNODE(X, 'P0/[P0N0=21]') 

The above operation tests whether the XML document "X" has an element called 
PO, which in turn has a child called PONO whose value is 21 . 

An example of the operation for transforming the XML document using a XSL 
stylesheet is as follows: ' 

TRANSFORM (X, '<xsl> . . ....stylesheet ..... </xsl>') 

The above operations are completely agnostic as to the underlying storage format 
of the XML document. 

QUERY REWRITES 

According to certain embodiments of the invention, a mechanism is provided for 
rewriting user queries into a form that leverages the data access and data manipulation 
capabilities of the underlyuig storage mechanism in the relational database. 

The fields of structured data of a given XML document may be mapped into 
separate relational colunms if the data in the fields is Mkely to be frequently queried by a 
user. For example, assume that one of the fields of an XML document contains an 
employee name, and that it is anticipated that users will frequently query the XML 
documents based on the employee name value. Under these conditions, employee names 
may be stored in a relational coliram called ENAME lliat is separate from the column that 
stores the XML document itself If a XML user submits a query to access XML 
dociraients based on a particular employee's name, then the XML user's query is 
automatically rewritten to access only the ENAME coluron. 

In contrast, if no query rewrite mechanism is provided and employee names are 
not stored in a separate column, then, when the XML user submits a query to access a 
XML documents based on a particular employee's name, a Document Object Model 
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(DOM) is created for each XML document by parsing the XML document. Then the 
search is performed on the DOM for the enq)loyee's name by applying an ^propriate 
XPATH expression. Creating a DOM and then performing a search on the DOM is 
clearly less efficient. 

In another example, the existing indexing capabiUties of the relational database 
are used to satisfy the XML user's query. If data is expected to be frequently queried, the 
data can be stored in a separate relational column, and a B-tree index may be built on that 
• column. Then, if an XML user query is submitted to select, for example, a row where 
P0N0=21, then the B-tree index on the PONG column can be used to identify the rows 
that contain XML documents that have the value 21 in the PONO colunm. Similarly, if an 
XML document is stored as a LOB, then a text index may be used to optimize a search on 
the LOB colmmi. 

A mechanism is provided in the database to generate a database query, for 
example a SQL query, based on the user's XML query and the mapping information 
associated with the storage of the XML document in the relational database. 

Referring to FIG. 5, assume that the table of FIG. 5 is called PO-TABLE and that 
a B-tree index is generated on the relational column PONO. Assume that an XML user 
submits the following query: 

SELECT * From PO-TABLE 

Where EXISTNODE (PO-XML, '/PO[PONO-21]') 

■ , According to certain embodiments of ttie invention, the above XML user's query 
is converted to the following: ^ 

SELECT * From PO-TABLE 
Where PO-XML .P0N0=21 

Thus, an index search can be performed for the predicate of PONO. 

HARDWARE 

FIG. 6 is a block diagram that illustrates a computer system 600 upon which an 
embodiment of the invention may be implemented. Computer system 600 includes a bus 
602 or other communication mechanism for communicating information, and a processor 
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604 coupled with bus 602 for processing information. Computer system 600 also includes 
a maia memory 606, such as a random access memory (RAM) or other dynamic storage 
device, coupled to bus 602 for storing information and instructions to be executed by 
processor 604. Main memory 606 also may be used for storing temporary variables or 
other intermediate information during execution of instructions to be executed by processor 
604. Computer system 600 further includes a read only memory (ROM) 608 or other static 
storage device coupled to bus 602 for storing static information and instructions for 
processor 604. A storage device 610, such as a magnetic disk or optical disk, is provided 
and coupled to bus 602 for storing information and instructions. 

Computer system 600 may be coupled via bus 602 to a display 612, such as a 
cathode ray tube (CRT), for displaying information to a computer user. An input device 
614, including alphanumeric and other keys, is coupled to bus 602 for communicating 
information and command selections to processor 604. Another type of user input device is 
cursor control 616, such as a mouse, a trackball, or cursor direction keys for communicating 
direction information and command selections to processor 604 and for controlling cursor 
movement on display 612. This input device typically has two degrees of freedom in two 
axes, a first axis (e.g., x) and a second axis (e.g., y), that allows the device to specify 
positions in a plane. 

The invention is related to the use of computer system 600 for implementing the 
techniques described herein. According to one embodiment of the invention, those 
techniques are implemented by computer system 600 in response to processor 604 
e{xecuting one or more sequences of one or more instructions contained in main memory 
606. Such instructions may be read into main memory 606 from another computer- 
readable medium, such as storage device 610. Execution of the sequences of instructions 
contained in main memory 606 causes processor 604 to perform the process steps 
described herein. One or more processors in a multi-processing arrangement may also be 
employed to execute the sequences of instructions contained in main memory 606. In 
alternative embodiments, hard-wired circuitry may be used in place of or in combination 
with software instructions to implement the invention. Thus, embodiments of the 
invention are not limited to any specific combination of hardware circuitry and software. 

The term "computer-readable medium" as used herein refers to any mediimi that 
participates in providing.instructions to processor 604 for execution. Such a medium may 
take many forms, including but not limited to, non-volatile media, volatile media, and 
transmission media. Non- volatile media includes, for example, optical or magnetic disks, 
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such as storage device 610. Volatile media includes dynamic memory, such as main 
memory 606, Transmission media includes coaxial cables, copper wire and fiber optics, 
including the wires that comprise bus 602. Transmission media can also take the form of 
acoustic or Ught waves, such as those generated during radio wave and iofiiBred data 
communications. 

Common forms of computer-readable media include, for example, a floppy disk, a 
flexible disk, hard disk, magnetic tape, or any other magnetic medium, a CD-ROM, any 
other optical medium, punch cards, paper tape, any other physical medium with patterns 
of holes, a RAM, a PROM, and EPROM, a FLASH-EPROM, any other memory chip or 
cartridge, a carrier wave as described hereinafter, or any other medium firom which a 
computer can read. 

Various forms of computer readable media may be involved in carrying one or more 
sequences of one or more instructions to processor 604 for execution. For example, the 
instructions may initially be carried on a magnetic disk of a remote computer. The remote 
computer can load the instructions into its dynamic memory and send the instractions over 
a telephone line using a modem. A modem local to computer system 600 can receive the 
data on Ihe telephone line and use an infrared transmitter to convert the data to an infrared 
signal. An infrared detector coupled to bus 602 can receive the data carried in the infrared 
signal and place the data on bus 602. Bus 602 carries the data to main memory 606, from 
which processor 604 retrieves and executes the instructions. The instructions received by 
main memory 606 may optionally be stored on storage device 610 either before or after 
execution by processor 604. 

Computer system 600 also includes la communication interfece 618 coupled to bus 
602. Communication interface 618 provides a two-way data communication coupling to a 
network link 620 that is connected to a local network 622. For example, communication 
interfece 61 8 may be an integrated services digital network (ISDN) card or a modem to 
provide a data communication connection to a corresponding type of telq)hone hne. As 
another example, communication interface 618 may be a local area network (LAN) card to 
provide a data communication connection to a compatible LAN. Wireless links may also be 
implemented. In any such implementation, communication interface 618 sends and receives 
electrical, electromagnetic or optical signals that carry digital data streams rqpresenting 
various types of information. 

Network link 620 typically provides data communication through one or more 
networks to other data devices. For example, network link 620 may provide a connection 
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througt local network 622 to a host computer 624 or to data equipment operated by aa 
Memet Service Provider (KP) 626. ESP 626 ia turn provides data communication 
services through the worldwide packet data communication network now commonly 
referred to as the "Ihtemet" 628. Local network 622 and hitemet 628 both use electrical, 
electromagnetic or optical signals that carry digital data streams. The signals through the 
various networks and the signals on network link 620 and through communication 
interface 618, which carry the digital data to and from computer system 600, are 
exemplary forms of carrier waves transporting the information: 

Computer system 600 can send messages and receive data, including program code, 
througih the network(s), network link 620 and communication interface 618. In the Internet 
example, a server 630 might transmit a requested code for an appUcation program through 
IntOTiet 628, ISP 626, local network 622 and conamumcation intorfece 61 8. In accordance 
with the invention, one such downloaded apphcation implements the techniques described 
herein. 

" The received code may be executed by processor 604 as it is received, and/or 
stored in storage device 610, or other non-volatile storage for later execution. In this 
manner, computer system 600 may obtain appUcation code in the form of a carrier wave. 

In the foregoing specification, the invention has been described with reference to 
specific embodiments thereof It will, however, be evident that various modifications and 
changes may be made thereto without departing from the broader spirit and scope of the 
invention. The specification and drawings are, accordingly, to be regarded in an 
illustrative rather than a restrictive sense. 
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CLAIMS 

What is claimed is: 

1 . A method for accessing data within a relational database, the method 

comprising the steps of: 

receiving, at a database server, a request that includes information in XML syntax, 
wherein the information specifies target data that resides in one or more portions of the 
relational database; 

determining, based on the information, the one or more portions of the relational 
database that correspond to the target data; and 

retrieving the target data from the one or more portions of the relational database. 

2. The method of Claim 1, ftirther comprising the step of, prior to receiving 
the request, providing an XML visualization of portions of the relational database based 
on access privileges of a user who is issuing the request. 

3. The method of Claim 1 , fiurflier comprising providing an XML 
visualization of portions of the relational database in response to the request. 

4. The method of Claim 1 , further comprising performing operations on the 
target data after retrieving the target data and wherein the operations on the target data are 
performed by issuing an Xpath notation to traverse an XML visualization of the one or 
more portions of the relational database. 

5 . ' The method of Claim 4, wherein the operations on the tai^et data comprise 
updating, deleting, reading, and inserting. 

6. The method of Claim 2, wherein providing the XML visualization 
comprises dynamically generating one or more XML schema based on the access 
privileges that the user has at a time of generating the one or more XML schema. 

7. The method of Claim 1, wherein the request is an Xpath query. 
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8. The method of Claim 7, wherein the Xpafh query is mapped into a SQL 

query. 

9. The method of Claim 7, wherein a translator of the Xpath query directly 
generates execute-time structures without being mapped into an SQL query. 

1 0. The method of Claim 1 , further comprising the step of creating a reference 
to the one or more objects of the relational database by using uniform resource identifier 
reference within the relational database. 

11. A method for accessing data in a relational database, the method 
comprising the steps of: 

establishing a mapping between Uniform Resource Locators (URLs) and data 
items within the relational database based on where said data items reside within a schema 
of theielational database; and - 

locating flie data items within the relational database based on the Uniform 
Resource Locators and the mapping. 

12. - The method of Claim 1 1 , wherein the step of locating includes : 

a database server receiving a URL that is mapped to a particular data item; and 
the database server deterrnming where the data item resides in the schema based 
on the URL and the mapping. 

13. The method of Claim 11, wherem the step of locating includes: 

an entity that resides outside a database server receiving a URL that is mapped to a 
particular data item; ^ 

the entity determining where the data item resides in the schema based on the URL 
and the moping; and 

the entity sending a message to the database server to cause the database server to 
access the data item, wherein the message mcludes mformation about where said data 
item resides in said schema. 
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14. The method of Claim 11, fiirflier comprising the step of storjng the URLs 
in a column of a table that stores the data items, wherein the URL that m^s to a particular 
data item is stored in said column within a row associated with that particular data item. 

15. The method of Claim 14, wherein one or more of the URLs include 
information indicating a data type of the data item associated with the URLs. 

16. Themethodof Claim 14, wherein: 

one or more of the URLs stored in the colmnn do not have portions that indicate 
certain information about where the corresponding data items reside; 

the method further includes a database server addmg the portions to said one or 
more URLs prior to providing said one or more URLs to any entity outside said database 
server; and 

the database server determines data type information of data items that are 
associated with the one or more URLs by accessing auxiliary information that is stored 
with the corresponding URL. 

1 7. The method of Claim 1 1 , wherein: 

the step of locatmg is performed by a database server; and ' 
the method further mcludes the step of the database server generating oulput in a 
form XML documents that include said data items. 

18. A method for accessing a data item stored in a relational database, the 
method comprising the steps of: 

generating, within a database server that manages the relational database, a 
Uniform Resource Locator (URL) for the data item based on where the data item resides 
within the relational database; 

providing the URL to an entity that resides outside the database server; 

receiving, at the database server, the URL; and 

in response to receiving the URL, resolving the URL within the database server to 
locate the data item. 
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19. The method of Claim 18, wherein the step of generating the 
URL includes adding to tlie URL data that indicates a data type associated 
with the data item. 

20. A computer-readable medium carrying instructions for accessing data 
within a relational database, the computer-readable medium comprising instructions for 
performing the steps of: 

receiving, at a database server, a request that includes information in XML syntax, 
wherein said information specifies target data that resides in one or more portions of the 
relational database; 

determdning, based on the information, the one or more portions of the relational 
database that correspond to the target data; and 

retrieving the target data ftom the one or more portions of the relational database. 

* 2 1 . The computer-readable medium of Claim 20, further comprising 
instructions for performing the step of, prior to receiving the request, providing an XML 
visualization of portions of the relational database based on access privileges of a user 
who is issuing the request. 

22. The computer-readable medium of Claim 20, further comprising 
instmctions for providing an XML visualization of portions of the relational database in 
response to the request. 

23. The computer-readable medium of Claim 20, further comprising 
mstructions for perfonning operations on the target data after retrieving the target data and 
wherein the operations on the target data are performed by issuing an Xpath notation to 
traverse an XML visualization of tiie one or more portions of the relational database. 

24. The computer-readable medium of Claim 23, wherehi the operations on the 
target data comprise updating, deleting, reading, and inserting. 

25. The computer-readable medium of Claim 21 , wherein providing the XML 
visuahzation comprises dynamically generating one or more XML schema based on the 
access privileges that the user has at a time of generating the one or more XML schema. 
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26. The computer-reaikble medium of Claim 20, wherein the request is an 
Xpath query. 

27. The computer-readable medium of Claim 26, wherein the Xpath query is 

mapped into a SQL query. 

28. The computer-readable medium of Claim 26, wherein a translator of the 
Xpath query directly generates execute-tune structures without being mapped into an SQL 
query. 

29. The computer-readable medium of Claim 20, further comprising 
mstructions for performing the step of creating a reference to the one or more objects of 
the relational database by using uniform resource identifier reference within the relational 
database. 

30. . A computer-readable medium carrying instructions for accessing data in a 
relational database, the computer-readable medium comprising instructions for 
performing the steps of: 

establishing a mapping between Uniform Resource Locators (URLs) and data 
items within the relational database based on where said data items reside within a schema 
of the relational database; and 

locating the data items within the relational database based on the Uniform 
Resource Locators and. the mapping. 

31. The coniputer-readable medium of Claim 30, wherein the step of locating 
includes: 

a database server receiving a URL that is mapped to a particular data item; and 
the database server determining where the data item resides in the schema based 
on the URL and the mappuig. 
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32. The computer-readable medium of Claim 30, wherein the step of locating 
includes: 

an entity that resides outside a database server receiving a URL that is mapped to a 
particular data item; 

the entity determining where the data item resides in the schema based on the URL 
and the mapping; and 

the entity sendmg a message to the database server to cause the database server to 
access the data item, wherein the message includes information about where said data 
item resides in said schema. 

33 . The computer-readable medium of Claim 30, further comprising 
instructions for performing the step of storing the URLs in a column of a table that stores 
the data items, wherein the URL that maps to a particular data item is stored in said 
column within a row associated with that particular data item. 

34. The computer-readable medium of Claim 33 , wherein one or more of the 
URLs include information indicating a data type of the data item associated with the 
URLs. 

35. The computer-readable medium of Claim 33, wherein: 

one or more of the URLs stored m the column do not have portions that indicate 
certain information about where the corresponding data items reside; 

the method further includes a database server adding the portions to said one or 
more URLs prior to providing said one or more URLs to any entity outside said database 
server; and 

the database server determines data type information of data items that are 
associated with the one or more URLs by accessing auxiliary information that is stored 

with the corresponding URL. 

36. The computer-readable medium of Claim 30, wherein: 
the step of locating is performed by a database server; and 

the computer-readable medium fiuther includes instructions for performing the 
step of the database server generating output in a form XML docimients that include said 
data items. 
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37. A computer-readable medium carrying instructions for accessing a data 
item stored in a relational database, the computer-readable medium comprisiag 
instructions for performing the steps of: 

generating, within a database server that manages the relational database, a 
Uniform Resource Locator (URL) for the data item based on where the data item resides 
within the relational database; 

providing the URL to an entity that resides outside the database server; 

receiving, at the database server, the URL; and 

in re^onse to receiving the URL, resolving the URL within the database server to 
locate the data item. 

38. The computer-readable medium of Claim 37, wherein the step of 
generating the URL includes adding to the URL data that indicates a data type associated 
with the data item. 

39. A method of providing data, the method comprising the steps of: 
receiving, at a database server, a relational database query to retrieve data that 

resides in a relational database; and 

the database server responding to the relational database query by providing a 
result of the relational database query fixim the relational database in a form of one or 
moje XML documents. 

40. The method of Claim 39, wherein the relational database query specifies 
which values that answer the relational database query are to be contained in the one or 
more XML documents, and which other values that answer the relational database query 
are to be referenced in the one or more XML documents by reference links. 

41 . The method of Claim 39, wherein the step of providing a result to the 
relational database query in a form of one or more XML documents comprises providing 
an XML document in which some values that are selected by the relational database query 
are contained in the XML document and other values that are selected by the relational 
database query are referenced in the XML document. 
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42. The method of Claim 39 further comprising the step of, during a 
processing of the relational database query, generating one or more XML-schema that 
describe features of the one or more XML documents, wherein the features comprise 
structure of the one or more XML documents. 

43 . The method of Claim 42 fiarther comprising storing at least one of the one 
or more XML-schema within at least one of the one or more XML documents. 

44. The method of Claim 39 further comprising the step of, during a 
processing of tiie relational database query, generating one or more XML -schema that 
describe features of the one or more XML documents, wherein the features comprise 
constraints of the one or more XML documents. 

45 . The method of Claim 42, wherein the one or more XML-schema 
corresponds to metadata that is associated with the data that is retrieved in response to the 
relational database query. 

46. The method of Claim 42, wherein the one or more XML-schema comprises 
relational database object types from one or more XML namespaces, wherein one or more 
relational database schemas are mapped to each of the one or more XML namespaces. 

47. The method of Claim 39, further comprising generating the one or more 
XML documents, and wherein the step of generating tiie one or more XlylL documents 
comprises using a set of rules that is stored m the relational database to detennme how to 
structure data contained in the one or more XML documents. 

48. The method of Claim 39, wherein the relational database query selects a 
plurality of rows in the relational database and wherein the one or more XML documents 
includes an XML document that aggregates data jOram the plurality of rows. 

49. The method of Claim 47, wherein the set of rules comprises mles for 
mapping a relational database object to a corresponding Database Uniform Resource 
Indicator reference. 
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50. The method of Claim 47, wherein the set of rules comprises rules for 
moping a query language reference to a corresponding Database Uniform Resource 
Indicator reference. 

51 . The method of Claim 47, wherein the set of rules comprises mles for 
mapping relational data that is associated with a LOB column to a corresponding 
Database Uniform Resource Indicator reference. 

52. The method of Claim 39, wherein the relational database query is satisfied 
by a plurality of rows and the one or more XML documents includes a suigle XML 
document for said plurality of rows. 

53. - A computer-readable medium carrying one or more sequences of 
instructions of providing data, which instructions, when executed by one or more 
processors, cause the one or more processors to carry out the steps: 

receiving, at a database server, a relational database query to retrieve data that 
fesides in a relational database; and 

the database server responding to the relational database query by providing a 
result of the relational database query from the relational database in a form of one or 
more XML documents. 

54. The computer-readable medium ofClaim 53, wherein the relational 
database query specifies which values that answer the relational database query are to be 
contained in the one or more XML documents, and which other values that answer the 
relational database query are to be referenced in the one or moK XML documents by 
reference links. ^ ■ 

55. The computer-readable medium of Claim 53, wherein the step of providing 
a result to the relational database query in a form of one or more XML documents 
comprises providing an XML document in which some values that are selected by the 
relational database query are contained in the XML document and other values that are 
selected by the relational database query are referenced in the XML document. 
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56. The computer-readable medium of Claim 53 flirther comprising the step of, 
during a processing of the relational database query, generating one or more XML-schema 
that describe features of the one or more XML documents, wherein the features comprise 
structure of the one or more XML documents. 

57. The computer-readable medium of Claim 56 further comprising storing at 
least one of the one or more XML-schema within at least one of the one or more XML 
documents. 

58 . The conq)uter-readable medium of Claim 53 further comprising the step of, 
during a processing of the relational database query, generating one or more XML - 
schema that describe features of the one or more XML documents, wherein the features 
comprise constraints of the one or more XML documents. 

- 59. The computer-readable medium of Claim 56, wherein the one or more 
XML-schema corresponds to metadata Ibat is associated with the data that is retrieved in 
response to the relational database query. 

60. The computer-readable medium of Claim 56, wherein the one or more 
XML-schema comprises relational database object types from one or more XML 
namespaces, wherein one or more relational database schemas are mapped to each of the 
one or more XML namespaces. 

61. The computer-readable medium of Claim 53, further comprising 
generating the one or more XML documents, and wherein the step of generating the one 
or more XML documents comprises using a set of rules that is stored in the relational 
database to detennine how to structure data contained in the one or more XML 
documents. 

62. The computer-readable medium of Claim 53, wherein the relational 
database query selects a plurality of rows in the relational database and wherein the one or 
more XML documents includes an XML document that aggregates data from the pteality 
ofrows. 
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63. The computer-readable medium of Claim 61, wherein the set of rules 
comprises rules for mapping a relational database object to a corresponding Database 
Uniform Resource Indicator reference. 

64. The computer-readable medium of Claim 61 , wherein the set of rules 
comprises rules for moping a query language reference to a corresponding Database 
Uniform Resource Indicator reference. 

65. The computer-readable medium of Claim 61, wherein the set of mles 
comprises rules for mapping relational data tittat is associated with a LOB column to a 
corresponding Database Uniform Resource Indicator reference. 

66. The computer-readable medium of Claim 53, wherein the relational 
database query is satisfied by a plurality of rows and the one or more XML documents 
includes a single XML document for said plurality of rows. 

67. A method for managing data in a relational database, the method 
comprising the steps of: 

receiving at a database server an XML document for storage in the relational 
database; 

storing in the relational database moping information that indicates a moping of 
one or more fields in the XML document to corresponding columns in the relational 
database; 

- storing data fix)m the XML document in the relational database in locations that 
are determined based on the mapping informationj and 

in response to the database server receiving a request for data firom the XML 
document, inspecting the mapping information to determine how to access the data fi-om 
the XML document. 

68. The method of Claim 67 further comprising the steps of: 

determining which corresponding columns in the relational database to use to store 
data from fields of the XML document; and 

generating the mappmg information of the one or more fields in the XML 
document to corresponding columns in the relational database. 
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69. The method of Claim 67, wherein the step of storing data includes the steps 

of: 

storing values for a plurality of fields of the XML document into a first column of 
a relational table; and 

storing values for at least one field of the XML document into a second column of 
the relational table, wherein the second column is different &om said first coltnnn. 

70. The method of Claim 67, wherein a request for data is an XML query. 

7 1 . The method of Claim 70, further comprising the steps of: 
generating a database query based on the XML query and the mapping 

information; and 

executing the database query to access data from the XML docimaent 

72 . The method of Claim 7 1 , wherein the database query directly accesses the 
underlying relational columns and uses indexes. 

73. The method of Claim 72, wherein the indexes are relational indexes. 

74. The method of Claim 72, wherein the indexes are text indexes. 

75 . The method of Claim 67, wherem a structure of the XML document is 
defined by a user to contain one or more fields of structured data, and wherein structured 
data is data that is of a type that corresponds to an existing relational data object type in 
the relational database. 

76. The method of Claim 67, wherein a structure of the XML document is 
defined by a user to contain one or more fields of unstructured data, and wherein 
unstructured data is data that is mapped to a LOB data type in the relational database 
during processing of the XML document for storage in the relational database. 



77. The method of Claim 67, wherein the mapping information is defined by a 

user. 
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78 . The mefliod of Claim 77, wherein the user has an option to map more than 
one field of the XML document to each column of the relational database for storage. 

79. The method of Claim 67, wherein an XMLType datatype is defined by a 
database server that manages the relational database for storing the XML document. 

80. The method of Claim 79, whereia a set of operations are defined for the 
XMLType datatype by the database server. 

81. The method of Claim 80, wherein the set of operations comprises, 
extracting fiagmeats of the XML document; 

testing for existence of one or more elements in the XML document; 
extracting one or more values firom the XML document; and 
transforming the XML docuinent 

82. The method of Claim 67, wherein: 

the mapping information maps a field of said XML document to a plurality of 
colimms of a relational table; and 

the step of storing data from the XML dociraient includes parsing said field of said 
XML document to identify a plurality of values and storing each of the plurality of values 
in a different one of said plurality of columns of the relational table. 

83. The method of Claim 67, wherein: 

the request specifies criteria for a field of the XML document; 
the method includes determining whether the criteria is satisfied by performing the 
steps of: 

determining, based on said mapping information, that the field is one of a plurahty 
of fields that is mapped to a particular colunm; 

parsing data in said particular column to locate a value of said field for said XML 
document; and 

determining whether said value satisfies the criteria. 
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84. A c^mpiiter-readable medium carrying one or more sequences of 
instructions for managing data within a relational database, which instructions, when 
executed by one or more processors, cause the one or more processors to cany out the 
steps of: 

receiving at a database server an XML document for storage in the relational 

database; 

storing in the relational database mapping information that indicates a mapping of 
one or more fields in the XML document to corresponding columns in the relational 
database; 

storing data from tiie XML document in the relational database in locations that 
are determined based on the m^ing information; and 

in response to the database server receiving a request for data from the XML 
document, inspecting the mapping information to determine how to access the data from 
the XML document. 

85 . The computer-readable medium of Claim 84 further comprising the steps 

of: 

determining which corresponding columns in the relational database to uise to store 
data from jBelds of the XML document; and 

generating the mapping information of the one or more fields in the XML 
document to corresponding columns in the relational database. 

86. The computer-readable medium of Claim 84, wherein the step of storing 
data includes the steps of: 

storing values for a plurality of fields of the XML document into a first colunm of 
a relational table; and 

staring values for at least one field of the XML document into a second column of 
the relational table, wherein the second column is different from said first column. 

87 . The computer-readable medium of Claim 84, wherein a request for data is 
an XML query. 



of: 



88. 



The computer-readable medium of Claim 87, further comprising the steps 
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generating a database query based on the XML quay and the mapping 
information; and 

executing the database query to access data fix>m the XML document. 

89. The computer-readable medium of Claim 88, wherein the database query 
directly accesses the underlying relational columns and uses indexes. 

90. The computer-readable medium of Claim 89, wherein the indexes are 
relational indexes. 

91. The computer-readable medium of Claim 89, wherem the indexes are text 
indexes. 

92. The computer-readable medium of Claim 84, wherein a structure of the 
XML document is defined by a user to contain one or more fields of structured data, and 
wherein structured data is data that is of a type that corresponds to an existing relational 
data object type in the relational database. 

93 . The computer-readable medium of Claim 84, wherein a structure of the 
XML document is defmed by a user to contain one or more fields of unstructured data, 
and wherein imstructured data is data that is mapped to a LOB data type in the relational 
database during processing of the XML document for storage in the relational database. 

94. Thecomputer^readablemediumof Claim 84, wherein the mapping 
information is defined by a User. 

95 . The computer-readable medium of Claim 94, wherein the user has an 
option to map more than one field of the XML document to each column of the relational 
database for storage. 

96. The computer-readable medium of Claim 84, wherein an XMLType 
datatype is defined by a database server that manages the relational database for storing 
the XML document. 
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97. The computer-readable mediimofClaim 96, wherein a set of operations 
are defined for the XMLType datatype by the database server. 

98. The computer-readable medium of Claim 97, wherein the set of operations 
comprises. 

extracting fragments of the XtvIL document; 
testing for existence of one or more elements in the XML document; 
extracting one or more values from the XML document; and 
transforming the XML document. 

99. The computer-readable medium of Claim 84, wherein: 

the mapping information maps a field of said XML document to aplurahty of 
columns of a relational table; and 

the step of storing data from the XML document includes parsing said field of said 
XML document to identify a plurality of values and storing each of the plurality of values 
in a different one of said plurality of columns of the relational table. 

1 00. The computer-readable medium of Claim 84, wherein: 
the request specifies criteria for a field of the XML document; 

the method includes determining whether the criteria is satisfied by performing the 
steps of: 

determining, based on said mapping information, that the field is one of a plurality 
of fields that is mapped to a particular colunm; 

parsing data in said particular column to locate a value of said field for said XML 
document; and 

determining whether said value satisfies the criteria. 
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